A number of different types of messaging communication models currently exist.    i) Synchronous messaging where a client sends a message to a server and requires a response before client processing proceeds. The client is unable to perform additional work until a response is received from the server,    ii) Asynchronous messaging where a client puts a request to a queue for background processing. The client can in the meantime process other work, safe in knowledge that a response will be received at some point.    iii) Pseudo Conversational Messaging where asynchronous messaging technology is used to send and receive messages but nevertheless, the client and server are expecting synchronous communication with one another, or any other differences between the client and server system capabilities.
The third model of communication is a common use of asynchronous messaging technology (for example IBM's WebSphere® MQ product). Note that this use of the words “client” and “server” refers to the logical relationship between the two computer systems and does not necessarily imply that the client computer system is using (for example) a WebSphere MQ client connection to a WebSphere MQ queue manager in the server computer system.
Typically, asynchronous messaging is chosen for reasons that include:    i) it provides simple interfaces to the programs running in the client system and the server system.    ii) It is available for a wide range of systems (computers, operating systems, and other software)    iii) It enables use of integration software (for example, IBM's WebSphere® Business Integration Message Broker)    iv) Many users prefer to use a single messaging technology so that they benefit from consistent operations and system management.
A pseudo-conversational messaging system is shown with reference to FIG. 1. Using pseudo-conversational asynchronous messaging, a client computer application 10 prepares a message (the request) and issues a PUT verb (step 1) to send the message to remote request queue 40. In accordance with asynchronous messaging practices client queue manager 70 first places the message on a local transmit (xmit) queue 20. The client queue manager then transmits the message from the local xmit queue 20 to server remote request queue 40, hosted on server queue manager 80 (step 2). Server application 30 issues a GET verb to retrieve the message (step 3), processes the message at step 4 (that is, performs the requested service), and PUTs a response message (step 5) to send the response message to the reply to queue 60 specified in the request message. The server queue manager first places the response message on its xmit queue 50 and then transmits the message to the client's local reply-to queue 60 (step 6). The client application 10 issues a GET verb to get the response message (step 7).
The server application uses transactional semantics so that the GET of the request, the processing, and the PUT of the response are either all completed (COMMIT) or are all backed out (BACKOUT or ABORT).
The client application however cannot simply include its PUT of the request (step 1) and its get of the response (step 7) in the same transaction. This is because the request message is not delivered to the server queue manager until the transaction that contains it COMMITS. The client application would lock-up indefinitely waiting for a response from the server before committing its transaction, yet the server application would not have received a request to process because the transaction had not committed.
The difficulty including steps 1 and 7 together in a transaction creates a problem for the client application regarding the appropriate behavior when no response message from the server application has been received within a reasonable period of time. This is particularly true because this model of messaging is pseudo-conversational (synchronous), rather than being true asynchronous messaging.
Thus when the client application does not receive a response from the server application, the client application is unsure as to whether its request has been/or will be processed by the server application.
Numerous techniques have been devised to deal with this problem. For example, the client application can specify a time-out value with the request. In this case, the message will be discarded if it cannot be delivered to the server application before the time expires. However, even in this case, the client application cannot assume that “no response” means the requested function was not performed. It might be that the response message from the server application has been delayed by, for example, network problems.
The client application could alternatively decide, having heard nothing, that the processing worked. Such an assumption could however be incorrect. It rather depends how important the client application's request was as to how much an incorrect assumption matters.
A compensating transaction can be used to compensate for the situation where it is wrongly assumed that a previous transaction did or did not happen. The compensating transaction negates the effects of the wrong assumption. It is however generally difficult for a program to generate a compensating transaction automatically.
Another option is to periodically poll (e.g. after a timeout period) the client application queue manager (which can in turn poll the server application's queue manager). This however adds additional (typically unwanted) complexity to the client application.